Summary of changes

Testing code for the Arduino Portenta, I noticed that its QSPI flash (MX25L12833F) was failing to init. Digging a bit deeper, it appears that it's hitting an assert failure in QSPIFBlockDevice::_enable_fast_mode(). This function is trying to enable fast mode using the 3rd status register, but the flash only has 2 status registers, so it dies.

As this comment explains, some flashes need this fast mode to hit their full clock frequency. However, MX25L12833F does not have a third status register and does not need fast mode -- it can run at up to 84MHz for a QSPI read without any special configuration (as far as I can tell from the datasheet).

The issue is that the logic in QSPIFBlockDevice::_handle_vendor_quirks() always sets _needs_fast_mode to true for Macronix devices, even if the QSPI_MACRONIX_NUM_STATUS_REGISTER option is set to 2. This makes it impossible to set QSPI_MACRONIX_NUM_STATUS_REGISTER to 2, because you will always get an assert failure.

To fix this, I tweaked the logic so that _needs_fast_mode is only set to 2 if we have 3 or more status registers, so we (think we) have the needed flag. Otherwise, we don't try to enable fast mode. I am not sure that this will work for all Macronix flashes, but it seems to work for the ones already supported and the MX25L12833F.

Update: Made a second fix after some more testing. The comment says that 4 byte mode does not work with Macronix devices, but the code did not actually follow through with that by setting _attempt_4_byte_addressing to false. Without this setting, testing on Arduino Portenta, the flash inits fine but data programmed to it is not actually saved and/or cannot be read back. So I went ahead and added _attempt_4_byte_addressing = false, and it completely fixed the issue.

Impact of changes

• Now possible to use Macronix QSPI flashes with QSPI_MACRONIX_NUM_STATUS_REGISTER set to 2 without hitting an assert failure.
• 4 byte addressing mode is now disabled for Macronix devices, regardless of SFDP table data

Migration actions required

Documentation

None

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[X] Tests / results supplied as part of this PR

Able to init the flash on an Arduino Portenta with this change.